場景：一封很短的信

信只有兩行：

本週五上午進行病歷品質稽核，抽查上月出院病歷二十份，敬請配合。

接下來三天，7B 病房的待辦清單會變短。護理紀錄補完、該簽的電子簽章補簽、上次稽核被點到的那幾項，這次不會再被點到。

星期五早上，稽核小組依抽查清單在系統裡調閱紀錄，單位窗口協助說明資料位置。該有的都有了。

這份通知由品管室依排程發出；查核、回覆與後續改善，分別落在稽核小組及受查單位的工作清單裡。我參與的是這些環節之間的討論。

而我很在意一件事：那二十份，是這個單位這個月最好的二十份。

先把一句話放在這裡，免得誤會：**這不是哪一家醫院的問題，是預告式稽核的結構必然。**全世界的 announced audit 都一樣——你預告，對方就有三天可以整理，而他整理出來的東西多半不是假的，是本來就該做、只是平常排不進去的那些。你們公司在合規稽核前一週補完的那批文件，也不是假的。預告改變的不是品質，是品質被看見的樣子。

（另一件事一次交代完：這個系列裡所有的單位、圈名、案例都是編出來的。7B 病房不存在，後面會出現的順安圈也不存在，會一路登場的陳護理長、資訊室的老周、品管室的小葉，同樣是好幾個真實情況揉出來的——因為真的那些我不能寫。這段話我只講這一次，之後不再聲明。）

這份工作是制度性地找麻煩

我在醫院參與品質改善工作。平常接觸的是各單位提出的問題、稽核回饋，以及大家討論「這樣改到底有沒有用」的過程。

用一句話解釋我在做什麼，最誠實的講法是：這份工作是制度性地找大家的麻煩。

這份工作分散在好幾個單位之間。

品管室協調排程與彙整結果，稽核小組依共同判準查核，各單位確認紀錄與流程、執行改善；判準有爭議時，要讓相關專業一起討論，需要跨單位決定的事項再帶進品質委員會。品管圈（各單位自己組隊做的改善專案）也由單位成員推動，品管團隊提供方法上的協助。我對每一份東西都有 blocking review，但沒有 write access。

我在文中會談自己參與討論時的觀察：**判準怎麼形成、不同判斷怎麼核對，以及理由怎麼說清楚。**寫 spec、審 PR、回到 postmortem 檢討，在這裡也需要不同角色接力。工作量要看整條流程花掉多少人力，不能只算某一個人讀了幾份。

當 7B 的陳護理長問「憑什麼說我們這份不合格」，稽核小組要提出依據，單位也要有機會補充系統紀錄與現場脈絡。我參與這類討論時，最在意的是雙方能不能對著同一筆資料說話。這份工作的重量，在於得說得出理由。

這件事先記著。整個系列會一再回到它——因為當我把判斷交給機器之後，「說得出理由」這個要求不會消失，它只是換了一個對象。

先說清楚這個系列不是什麼

這個系列不是要帶你認識醫院品管。

也不是要告訴你醫院有多少資源做 AI。這件事先講白，免得你把它讀成一份有錢單位的實驗紀錄——

• 人力有限，而且抽不出來
• 預算有限，還要跟一堆更急的事排隊
• 資料散在好幾套系統裡，彼此不通：病歷在一套、事件通報在另一套、稽核表還躺在某個人的 Excel 裡。中間沒有 pipeline，只有人在搬
• 老手的判斷帶不走。人退休了，那套標準跟著走——因為它從來沒有被 commit 過

這四件事，跟你們一模一樣。

所以重點不是我們做了什麼醫療 AI，是資源有限的條件下，一個 AI 專案怎麼從零走到真的有人在用。

這也是我想把這些經驗寫給 IT 讀者的理由：資料已經電子化，卻仍要跨系統查閱、逐筆確認，再交給下一個角色。系統裡有資料，跟單位能用它完成工作，中間還隔著一段流程。這段距離，在你們的內部工具裡也找得到。

回到你這邊。把名詞換掉，你會發現這套流程你每天都在跑：

這不是我在做類比修辭。兩邊處理的是同一個結構問題：

在一個必然會出錯的系統裡，建立一組回饋迴路，讓錯誤在造成損害之前被看見——而且不要吵到讓人把警報關掉。

而處理這個結構問題的方法論，醫療業一樣都沒有發明。管制圖是 Shewhart 在貝爾實驗室畫出來的，PDSA 是 Deming 帶去日本製造業的，抽驗的邏輯來自 AQL，連「進料、製程、出貨三道檢驗」也是工廠的東西。醫療業是後進者——我們是借的人，不是發明的人，而且借得比製造業晚了幾十年。

這 30 天我要做的不是介紹它們，而是把這套流程拆開來，看哪一段接得上資訊流程、哪一段接不上、接縫在哪裡會裂開。

這份工作最大的悖論

回到那封信。

稽核有一個從第一天就存在、永遠解不掉的問題：一旦宣告要看，現場就會變好。

做研究的人有一個名字給它：霍桑效應——知道自己正在被觀察，行為就會改變，而且改的方向通常剛好是觀察者想看到的那個方向。這件事有個更難聽的講法：我們每一次稽核，都是一場提前三天公告的 load test。

可以不預告，但突襲稽核破壞信任、消耗現場，一年做不了幾次。

也可以增加樣本，但稽核的吞吐量就這麼多——它等於稽核小組排得出來的人力，乘上每一份要跨頁籤確認的欄位數，而全院一個月出院的電子病歷以千計。

於是這份工作長期停在一個尷尬的位置：用最嚴謹的方法，看著最不具代表性的那一小撮樣本，然後對整體品質下結論。

你的 sample 不會知道自己被 sample 到。我的會，而且它有三天可以準備。

我們看到的永遠是準備過的版本。這是品管工作的原罪，也是我後來會想把 AI 拉進來的全部理由。

最耗人的不是讀，是判斷

讀不完，那就多找幾個人讀？

問題是，這份工作最耗人的從來不是讀，是判斷。

一份病歷擺在面前，要回答的不是「上面寫了什麼」，而是「這樣算不算不合格」。護理紀錄晚了兩小時補登，算不算缺失？一份品管圈報告的對策寫「加強教育訓練」，算不算有效對策？我心裡有答案，但我得說得出理由——而且下一位委員看同一份的時候，最好給出一樣的答案。

現在把這件事放到你的系統裡。假設要你把它自動化，第一步會做什麼？

寫規則。

if (補登時間 - 事件時間) > 2小時:
    return 缺失

這條規則五分鐘就寫得出來，然後五分鐘後就被推翻：病人當時在急救，紀錄當然晚。那就加例外。加完之後還有轉床、還有交班中斷、還有那些沒人想得到、但每個月都會發生一次的狀況。

問題不在規則寫得不夠好。問題是這類判斷本來就不是規則形態的。它是在一組互相拉扯的考量之間，做出一個可辯護的取捨。

醫院資訊化卡住的那條線

這正是醫院資訊化卡了幾十年的地方：

• 能寫成規則的部分，二十年前就自動化了——欄位必填、時間戳檢核、代碼比對、藥品交互作用警示
• 剩下的都是寫不下來的部分，所以剩下的都還是人在做

每一輪資訊化投資，最後都停在同一個地方。這條線有個名字：判準的形式化極限——線的右邊，是一整區永遠寫不出 spec 的需求。

線的左邊條件明確、輸入結構化、對錯可判定；線的右邊條件互相拉扯、輸入是一段自由文字、對錯要看情境，而且要說得出理由——那是品質團隊與各單位每天要一起面對的事。

過去二十年，這條線幾乎沒有移動過。

LLM 讓這條線鬆動了

而 LLM 第一次讓它鬆動。不是因為它比人聰明，是因為它接受用自然語言描述的判準，而不是只接受布林運算式。

同一個判斷，現在可以這樣寫：

判斷這筆護理紀錄補登是否構成品質缺失。
考量：紀錄類別、當時的照護強度、是否影響後續臨床決策。
若當時病人正在急救，延遲補登不構成缺失。
輸出：判定結果、理由、你對這個判定的把握程度。

這段東西你看得懂，機器現在也「看得懂」。注意最後一行——我可以要求它說出理由，這在規則引擎的世界做不到。

但看得懂不等於判得準，判得準也不等於每次都判一樣。

把判準從程式碼搬到自然語言，你會立刻撞上自然語言本身的問題：歧義、尺度不一致、同一句話兩個模型讀出兩個意思。你把一個編譯期就會爆的問題，換成了一個要到上線後才會慢慢浮現的問題。

於是有三個問題必須被回答，否則這條鬆動的線沒有意義：

1. 判準寫成自然語言之後，怎麼確認機器理解的跟你一樣？（第三、四週）
2. 一個沒有標準答案的任務，怎麼驗證它判得對？（第四週，我最想寫的部分）
3. 它今天判得準，下個月模型換版之後還準嗎？（第五週）

這三個問題就是這 30 天的骨架。

所以，這 30 天要做什麼

實驗命題一句話：

把一段規則寫不下來、只能靠人判斷的品質流程，改造成一條資訊流程——AI 跑得動、輸出驗得了、團隊敢用。

「敢用」三個字是整個系列的重量所在。做一次能用的示範不難——挑一份漂亮的案例、餵一段精心調過的 prompt、截圖，很好看。難的是把它放進一個每個月都要跑、而且結論會影響到別人的流程裡。

那需要三件事：

• 可重現 — 不是模型每次一樣就好，是同一份東西換一位委員、換一個月，結論要一樣
• 可觀測 — 它判錯的時候，要有東西讓人看得出來。看不見自己何時出錯的系統，沒有資格上線（明天整篇談這個）
• 可歸責 — 判錯了要有人到品質委員會上說明。exit code 不能出席委員會

三件事有一個共同點：它們都不是「模型夠不夠強」的問題。這是我想寫這個系列的原因——大部分關於 AI 落地的討論停在模型能力，但真正卡住的地方從來不在那裡。

三個限制條件，先講清楚：

第一，我不是工程師，但這系列不會迴避技術。 我的專業是品質管理、統計驗證、臨床判斷，所以不會有框架教學或程式碼導讀——那不是我的位置。我會寫的是另一層：流程怎麼拆給模型、判準怎麼寫成機器判得動的條目、輸出怎麼驗、它在哪一步壞掉、模型換版之後怎麼發現標準悄悄位移了。寫系統的行為與失效，不寫系統的實作。

第二，我不能拿真實資料亂試。 病歷不上雲端，院內文件不外流，事件通報不寫進文章。所有數字都是示意值。這不是保守，是底線——而它同時逼出一個很硬的技術問題：沒有真實資料，要怎麼驗證一套判斷系統？ 那是第四週的主題。

第三，我會寫失敗。 每篇最後有一個固定欄位：今天 AI 幫我省了什麼、幫倒忙在哪。「幫倒忙」那半邊不是花絮，是失效紀錄。我關心的不是它某一次答錯，而是它穩定地往哪個方向錯——有方向的錯誤才修得動，隨機的錯誤只能防。

而失敗不會只有模型的份。回看過去參與過的預警系統，我曾經很在意模型預測得準不準，後來才慢慢明白，單位收到預警後能不能接著處理，是另一個必須回答的問題。第四週會回來講這件事，那大概是這 30 天裡我對自己最不客氣的一篇。

完整路線 Day 6 交代。

如果你只帶一句話走

你會做的自動化，處理的是規則寫得下來的事。這 30 天談的是規則寫不下來的那一半。

這一半在你的系統裡也存在。哪些 PR 該擋、哪個 alert 值得半夜叫人起來、這次 incident 的根因寫得算不算合格、這份技術文件算不算「寫完了」——你多半也是靠人判斷，靠資深的人判斷，而且換個人結論就變。

你們叫它「靠經驗」「靠 sense」「這個要 senior 才看得出來」。我們叫它「專業判斷」。是同一件事：判準存在，但沒有被寫下來。

醫療業借這套東西借得比較徹底，不是因為我們比較聰明，是因為判錯的後果會落在一個具體的人身上。於是那些工具在醫院被磨出一套處理人為判斷的用法。

這 30 天，我把這套工具攤開來，然後拿現在的 AI 去撞它。撞得動的地方我會寫，撞不動的地方我也會寫。

明天談一個更根本的問題：品質到底是什麼。答案跟大多數人的直覺相反，而且它對你的系統一樣成立。